مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
|
|
این مطالب از زبان یکی از اعضای این پروژه(احسان میرسعیدی) که به عنوان برنامه نویس فعالیت میکرد بیان شده است،که بخاطر اینکه این پروژه،یک پروژه ملی بوده از توضیح مشخصات بیشتر خودداری کرده است ولی من از جهت اینکه دلایل شکست را بخوبی شرح داده است،از آن استفاده کردم. · * مشخصات و هدف پروژه: این پروژه قرار بود زیرساخت های یک سازمان عریض و طویل کشوری را دگرگون کند. پروژه ای ERPمانند بود و قرار بود عمده کار تحت بستر وب توسعه پیدا کند. تقریبا از شهریور ماه سال 91 درگیر یکی از پروژه های ملی و بزرگی شدم که اگر درست و صحیح به ثمر می رسید، می توانست تغییراتی بنیادین، ساختاری و مدرن را در بدنه یکی بزرگ ترین سازمان های مهم و حیاتی کشور اعمال کند. متاسفانه این پروژه به دلایل مختلفی به عقیده من شکست خورده است و تا تغییرات اساسی در نحوه فرایند تولید نرم افزار ایجاد نشود، کار برای همیشه زمینگیر خواهد شد و یا در بهترین حالت پولی از بیت المال صرف نرم افزاری می شود که کوچک ترین کارایی و کیفیتی نخواهد داشت. · * دلایل شکست پروژه: در ادامه دلایلی را که به عقیده من منجر به شکست پروژه شده است را تشریح خواهم کرد. این دلایل هیچ تقدم و تاخری ندارند و هر کدام از آن ها می تواند به تنهایی یک پروژه را زمین گیر کند. همه آنچه که در زیر می آید، در یک کلام خلاصه می شود و آن حرفه ای نبودن است. نرم افزار خوب و با کیفیت از آن دست محصولاتی نیست که برای تولید اش راهی به جز حرفه ای بودن وجود داشته باشد. حرفه ای بودن یک شرکت - مخصوصا در مقیاس پروژه های ملی- نه تنها در زمینه توسعه و کدنویسی خود را نشان می دهد، بلکه حرفه ای بودن بایستی در تحلیل ها و طراحی ها، در مصاحبه ها و نیازسنجی ها و مدیریت مشتری، مدیریت تیم نرم افزاری، مدیریت پروژه و دانستن نحوه رفتار با توسعه دهندگان و باقی مسائل حرفه ای منعکس گردد. آیا می توان یک پروژه ملی را بدون در نظر نگرفتن استاندارد ها و کیفیت پیش برد؟ 1 . ابزارهای توسعه بی کیفیت برای توسعه این سامانه از ابزاری به نام Wavemaker استفاده شده است. این ابزار اگر چه از فریم ورک های مهمی چونHibernate و Spirng و Dojo بهره می گیرد اما به طور کلی ابزاری است که کاری جز خراب نمودن و کند کردن روند کار شما نخواهد داشت. این ابزار اگر چه ادعا می کند که از نوع RAD می باشد، اما هنر اصلی این ابزار ارائه کاری بی کیفیت، غیر قابل پیشبینی و زشت و برهنه (البته از لحاظ امنیتی!) است که در زمانی بسیار بیشتر از حداکثر زمان ممکن، طراحی و توسعه داده می شود. 2. کم مهارت بودن اعضای تیم پروژه هایی در این سطح نیاز به افراد متخصص و حرفه ای دارند. متاسفانه افراد تیم ما، افرادی بودند که سابقه چندانی نداشتند.اگر نگوییم اولین پروژه، که اولین پروژه جدی و بزرگشان، همین پروژه بود. همین باعث شد در بسیاری از مواقع، کارها دچار دوباره کاری، کثیف کاری و ندانم کاری ها شود و روند توسعه به شدت کند و بی کیفیت گردد. همین باعث شد تا نرم افزاری توسعه داده شود که در بسیاری از قسمت ها، بارها و بارها از صفر نوشته شد، بسیاری از قسمت ها بی کیفیت و کند بود و یا اینکه هر کسی نمی توانست بر روی قسمتی که کسی دیگر کار کرده است کار کند. 3. کم بودن نفرات تیم به تجربه برای من ثابت شده است که برای انجام کار با کیفیت، سازمان بایستی به طور با کیفیتی پول هزینه کند. یکی از موارد این هزینه ها هم، استخدام تعداد پرسنل کافی و حرفه ای است. این پروژه دارای گستردگی بالا، تعدد ذینفعان، نقش ها و نیازمندی های مختلفی بود. به همین دلیل به باور من، تیم ما در قسمت نیازسنجی، حداقل به چهار نفر نیاز داشت. اما در بیشتر دوران این ده ماه، کل تیم فقط از سه نفر تشکیل شده بود. گاهی هم نفر دیگری به پروژه اضافه می شد و مسئولیت استخراج نیازمندی ها را بر عهده می گرفت. یکی از علل عقب افتادن تحویل پروژه و بی کیفیتی کار، این بود که این پروژه به شدت از کمبود نیرو رنج می برد. 4. ضعف در استخراج نیازمندی ها عامل شکست بیش از هشتاد تا نود درصد پروژه ها، ضعف در تحلیل نیازمندی ها می باشد. بلایی که گریبانگیر این پروژه هم شد. در مراحل اولیه از سمت شرکت اجازه استخراج نیازمندی ها به ما داده نشد. حتی در جلسه ای که با یکی از ذینفعان بود، من تعدادی سوال در رابطه به نیازمندی های شان پرسیدم که بعدا مواخذه شدم. در سه ماه اول، نیازمندی ها از طرف شخص ثالثی که دید و شناخت بسیار محدودی از پروژه داشت، به ما ارائه می شد. مطالبی که به دست ما می رسید، بسیار آشفته و سردرگم و پر از ابهام بود و مرجعی هم برای پاسخگویی به سوالات و رفع ابهامات تیم وجود نداشت. حاصل کار هم چیزی جز دوباره کاری و سردرگمی نبود. ماحصل کار هم پس از سه ماه به سطل آشغال ریخته شد. آن فرد کنار رفت و فرد دیگری به تیم ما اضافه شد و مسئولیت مصاحبه ها و استخراج نیازمندی ها را بر عهده گرفت. این فرد، متاسفانه پیش از این هیچ سابقه ای در نیازسنجی نداشت و نبایستی تمامی این کار در اختیار و حیطه مسئولیت این فرد، به تنهایی، قرار می گرفت. او نتوانست که اطلاعاتی را که در مصاحبه و جلسات کسب کرده مکتوب کند و در اختیار تیم بگذارد. او نتوانست در مصاحیه هایش تفکرات ناصحیح کارفرما را اصلاح کرده و به او دید صحیح بدهد. این ها نمی دانستند که نرم افزار قلمرو ابهامات نیست، که جایگاه جزییات و دقت هاست. 5. حقوق پایین و حتی عدم پرداخت همانطور که بیان شد، کار با کیفیت نیاز به خرج با کیفیت دارد. متاسفانه بازه حقوقی کارکنان بسیار پایین بود. با توجه به حجم و زحمت کار، نیاز به دریافت مبلغ بیشتری بود تا کارمندان انگیزه تحمل فشارها و ناملایمت های محیط کار را داشته باشند. اما متاسفانه به علت پایین بودن حقوق ها، به مرور انگیزه ها کم شد و تیم دچار فرسایش روحی و انگیزشی شد. دیگر به جایی رسیدیم که در شرکت عملا کاری انجام نمی گرفت. عامل دیگری که باعث کاهش انگیزه پرسنل می شود، مقایسه خود با همکاران در شرکت های دیگر است. که این مقایسه خواه ناخواه صورت می گیرد. 6. دروغگویی در جلسات یکی از عواملی که باعث شد که اعتبار شرکت نزد کارفرما ضربه بخورد، دروغ گویی های بی حد و حصر مدیران در جلسات بود. مدیری در جلسات حضور می یافت و در صورتی که نرم افزار را ندیده بود، چنان از ویژگی های عجیب و غریب سامانه و هزینه های هنگفتی که برای آن شده است، سخن می گفت که ما خودمان حیرت می کردیم. 7. ارائه تخمین های غلط به کارفرما هم کسی که مدیر پروژه شده بود و هم مدیرانی که در جلسات شرکت می کردند، بسیار وعده های عجیب و غریبی نسبت به زمان آماده سازی برخی قابلیت ها می دادند. قول هایی که داده می شد مبتنی بر واقعیت های تولید نرم افزار نبود و زمانی که لازم است تا چرخه استخراج نیازمندی، تحلیل و پیاده سازی و تست طی شود را درنظر نمی گرفت. این تخمین های ناصحیح باعث می شد تا شب های زیادی تیم در شرکت بماند و یا بالاجبار روزهای تعطیل بیاید و اضافه کاری های سنگیی را متحمل شود. البتهدر پروژه ما، نتیجه همه این شب کاری ها و اضافه کاری ها، در نهایت دور ریخته شد. چرا که کارمندان تحت فشار ،کار با کیفیت تولید نمی کنند. 8. مهارت و تعهد پایین مدیران شرکت دارای دو مدیر فنی بود. هر دو از تحصیل کردگان شاخص دانشگاه امیرکبیر در رشته هوش مصنوعی بودند. متاسفانه نفر اصلی به ندرت در شرکت حضور داشت و در جریان کارها و هماهنگی های پروژه نبود. دیگری هم بیشتر درگیر کارهای شخصی خودش بود. آگاهی ای نسبت به ظرافت کاری های پروژه و موانع و مشکلات آن نداشتند. 9. عدم احترام به پرسنل موضوعی که همه پرسنل نسبت به آن ناراضی بودند، عدم رعایت احترام آن ها از سمت مدیران بود. اگر چه شرکت از جهات مختلف دارای ضعف های عمده بود، اما مدیریت به جای اینکه با رفتارش کارمندان را جذب کند به نوعی موجب دلسردی آن ها شده بود. نگاهی از بالا به کارمندان داشتند. صدای انتقادات آن ها شنیده نمی شد و نتیجه هم جز این نبود که همین موجب ایجاد نارضایتی زیادی در کارمندان شد و این نارضایتی در کاری که انجام می دادند منعکس شد. حلقه معیوبی از نارضایتی شکل گرفت که مدام تشدید می شد. همچنین عدم حل مشکلات در بالا و ایجاد محدودیت برای کارمندان موجب شد، تا به جای اینکه ذهن کارمندان آرامش داشته باشد، مدام درگیر و دار ناراحتی و نارضایتی باشد. 10. عدم تعهد پرسنل به انجام کار خوب از ویژگی های مهمی که باعث می شود تا هر کس در کارش پیشرفت کند، تعهد می باشد. تعهد به انجام کار خوب و باکیفیت فرد را در مسیر حرفه ای رشد می دهد. این ویژگی در فرد موجب می شود تا کاری که آماده می کند بهترین کیفیت ممکن را داشته باشد و مطمئن باشیم که فرد به همه وجوه مختلف آن فکر کرده است. متاسفانه اعضای این پروژه این تعهد حرفه ای را به خود، تیم و پروژه نداشتند. موجب شد در مدت این ده ماه نه چیزی به دانش شان اضافه شود و نه کاری که آماده می کنند دارای کیفیت شاخص و ممتازی باشد. 11. عدم وجود تست در مورد عدم وجود تست پلن و مسائل مربوطه نیازی به توضیح نیست. آیا انجام پروژه بزرگ، بدون وجود انواع و اقسام تست های حرفه ای ممکن است 12. عدم مستند سازی در این پروژه بعد از ده ماه، هنوز یک صفحه مستندات آماده نشده بود تا بدانیم هر ذینفعی دارای چه نوع نیازمندی هایی می باشد. این هم به این معنی است که بر روی هیچ یک از نیازمندی ها توافق قطعی صورت نگرفته بود. در نتیجه نه نیازسنج ما راهی داشت تا بفهمد که سخنان کارفرما را به درستی درک کرده و نه کارفرما راهی داشت که بداند آیا سخنان اش را کامل و به درستی منتقل کرده است. سندی آماده نبود که بر طبق آن سامانه طراحی شود. این موجب شد که اگر جایی خطایی در طراحی و پیاده سازی انجام می شد و یا موضوعی فراموش می شد، نتوانیم با مقایسه با سند نیازمندی کارمان را ارزیابی کنیم. این امر هم باعث شد تا بسیاری از قابلیت ها در نرم افزار توسعه داده شود که بعد ها کارفرما ادعا کرده آن ها را نمی خواهد و یا منظورش جور دیگری بوده است. بسیاری از قابلیت ها از جلساتی که با مدیران داشتند بیرون آمد. در این جلسات به طور آنی و بدون فکر قبلی بسیاری از ایده ها مطرح می شد و شخص نیازسنج بدون هیچ گونه تحلیل و مکتوب نمودن، آن ها را در طراحی سامانه منعکس می کرد. همین هم باعث شد، تا این ایده های ناقص الخلقه با ورود شان به سیستم تنها انرژی، انگیزه و پول تیم را هزینه کنند، بدون اینکه هیچ ارزش افزوده ای به پروژه اضافه کنند. 13. عدم وجود متدلوژی برای توسعه نرم افزار توسعه نرم افزار، بسیار وابسته به نحوه تعاملات اعضای تیم و رابطه اصولی و تدوین شده کارفرما و پیمانکار می باشد. پروژه های بزرگ نرم افزاری را نمی توان به سبک یک هیئت اداره کرد و انتظار داشت تا همه چیز طبق برنامه و خواست ذهنی ما پیش برود. بسیار بسیار پیشتر، بزرگان این صنعت در غرب این مسیر را طی کرده اند و از شکست های شان آموخته اند که باید پروژه های نرم افزاری بر اساس قاعده و اصول خاص و مشخصی در حیطه تولید، تعاملات داخلی و خارجی پیش برد. یادگیری اصولی و رعایت این قوانین و چارچوب ها در کتاب ها پیدا نمی شود. نمی توان صرفا با مطالعه کتب مختلف راجع به SCRUM، به مدیریت نکات و نقاط بحرانی پروژه واقف شد. چرا که هر پروژه شرایط خاص خودش را دارد. کارها در شرکت نظم و ترتیب مشخصی برای انجام نداشت. کارها زمان مشخصی برای پایان نداشت. برای همین کار برای مدت ها در شرکت به حال خود رها میشد. نبودن milestone و نداشتن deadline تیم را تنبل و بی انگیزه می کند. تیم برای جنگیدن بهانه و انگیزه ای نخواهد داشت و این اتفاق تیم را سست می کند. از طرف دیگر، نداشتن نظم موجب می شد تا کارفرما ناگهان اعلام کند که درخواست های زیادی را که در گذشته مطرح کرده برای یکی دو روز آینده می خواهد. این موجب میشد تا تیم از خواب خرگوشی بلند شود و شب و روز در شرکت بماند تا کار را تحویل دهد. · * نتیجه ای که من از این مطلب گرفتم این است که از این 13موردی که نویسنده به عنوان دلایل شکست پروژه مطرح کرده است میتوان گفت تقریبا نیمی از آنها به دلیل عدم نیازسنجی صحیح اتفاق افتاده است. نداشتن برنامه ریزی دقیق و عدم جمع آوری اطلاعات مورد نیاز قبل و در حین پروژه باعث بهم ریختگی و به نتیجه نرسیدن تلاش های تیم شده است.
|
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
|
|
-مشخصات پروژه :
اهداف پروژه :
نتيجه اجراي پروژ :
درس هاي گرفته شده از پروژه :(عدم نياز سنجي صحيح)
در 2013بخش موبایل نوکیا به مایکروسافت منتقل شد. بدین ترتیب تولید گوشیهای نوکیا با نام نوکیا میکرو سافت موبایل تولید میشوند (به مدت ۱۰ سال) |
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
|
|
نیاز سنجیاصولا زمانی که سازمانهایی که کسب وکارشان از طریق انجام پروژه هاست، رشد کرده و تعداد و پیچیدگی پروژه ها افزایش پیدا می کند، بهترین روش مدیریت کارآمد وبهره ور پروژه ها، مدیریت از طریق "پیاده سازی دفتر مدیریت پروژه" است. در موارد زیر این اهمیت بروز و نمود بیشتری خواهد داشت:
انتخاب 6 مورد یا بیشتر: ایجاد دفتر مدیریت پروژه قویا توصیه می شود انتخاب 10 مورد یا بیشتر: ایجاد دفتر مدیریت پروژه ضروری است
2. متدولوژی مدیریت پروژه به صورت گسترده پذیرفته و بکار گرفته نشده است 3. درخواستهای تغییر محدوده خارج از کنترل پروژه هستند 4. یک استخر منابع مشترک برای چندین پروژه در نظر گرفته شده است 5. کمبود تخصصهای مدیریت پروژه در حوزه های مورد نیاز وجود دارد 6. چندین تامین کننده کالا و خدمات بطور مشترک در پروژه ها استفاده می شود 7. نیاز مبرمی برای یکپارچه کردن گزارشها و معیارها وجود دارد 8. زمان تحویل محصول یک عامل کلیدی موفقیت محسوب می شود 9. هزینه های کلی و بالاسری پروژه بسیار بالا است 10. استخر منابع سازمان با نیازمندی های تخصیص منابع در پروژه ها همخوانی ندارد 11. آموزشها در بهبود عملکرد پروژه موثر نیست 12. برنامه جذب نیروی انسانی پروژه اثربخش نیست 13. بهره گیری از بهترین عملکردها با مشکل مواجه است 14. کنترلی بر سبد پروژه وجود ندارد 15. هیچ هماهنگی در ارائه گزارش های وضعیت پروژه و گزارشهای تحلیلی وجود ندارد 16. تداخلهای زیادی در زمان بندی منابع وجود ندارد 17. فاصله قابل توجهی بین بلوغ فرایندهای مستند شده و بلوغ اجرای آنها وجود ندارد. [۱] |
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
|
|||||
400 میلیون تومان خرج کپی مرورگر ملی
|
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
|
|
سلام علیکم هر پروژه اگر خلاقیت و پشت کار و پشت بانه مالی نداشته باشد حتما شکست خواهد خورد . اگر نگاهی سطحی به شرکت تولید نی شکر در ایران داشته باشیم با گفتن اینکه این مکان قدیمی است و بیش از تولیدش دارد مصرف می کند با این سیاست غلط هزاران نفر بیکار و تولید نی شکر به صفر رسید تا انجا که باید واردات داشته باشیم و این نگاهی کوچک بود اما در سطح وسیعتر چه؟ |
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
|
|
پس از سپری شدن دو سال از معرفی عینک گرانقیمت شرکت گوگل، کارشناسان معتقدند که این پروژه هیچ وقت به موفقیت پیشبینی شده نرسیده است. به گزارش سرویس علمی ایسنا منطقه خراسان، کارشناسان معتقدند که با توجه به قیمت بسیار بالای 1500 دلاری و برخی از تبلیغات اغراق آمیز در مورد کاراییهای این عینک، بیشتر کاربران استفاده از عینک را محدود کرده و اغلب از کارایی آن ناراضی هستند. یکی از دلایل موثر در کمرنگ شدن موفقیت عینک گوگل، کافی نبودن برنامههای ارتباطی آن با گوشیهای هوشمند است، به طوریکه تاکنون تنها در حدود 100 برنامه کاربردی برای این عینک موجود است که اغلب از رابط کاربری ضعیفی برخوردارند. به گفته تام فرانکل، مدیر اجرایی شرکت گایگیم، اگر طبق ادعای گوگل تاکنون 200 میلیون عینک به فروش رفته باشد نباید شاهد ترک مدیران بخش طراحی و ساخت پروژه عینک گوگل باشیم. کریس نیل، مدیر پروژه عینک گوگل با اشاره به زمانبر بودن روند محبوب شدن پروژههای غیرعادی نظیر عینک گوگل افزود: پروژه عینک گوگل تنها یکی از دستاوردهای آزمایشگاه گوگل ایکس است. وظیفه این بخش تولید و تجاری کردن پروژههای آیندهنگر گوگل نظیر خودروی خودران هوشمند و ابزارهای پوشیدنی است. کارشناسان ابر صنعت IT معتقدند با توجه به وعدههای شرکت گوگل بر عمومیسازی پروژه عینک گوگل در سال 2015 و رضایت کم کاربران از نسخه آزمایشی احتمال موفقیت این پروژه کم است.
تحقيقات اخير نشان داده است كه حدود 62 درصد پروژههاي IT در زمان تعيين شده و يا با هزينه پيشبيني شده نتوانستهاند به انجام برسند. به طور كلي دلايل اصلي شكست پروژههاي IT عبارتند از : Poor Planning (طرح ريزي ضعيف) ) Unclear Goals and Objectives اهداف و مقاصد غيرشفاف و نامشخص) ) Objective Changes during Projects تغييرات اهداف پروژه در حين انجام آن) ) Unrealistic Time or Resource Estimate پيشبيني غيرواقعي زمان و يا منابع پروژه) ) Lack of Executive Support and User Involvement نقصان پشتيباني اجرايي و درگير نمودن كاربران در پروژه ) ) Failure to Communicate and Act as a Team شكست در ايجاد ارتباط مدير پروژه با تيم پروژه) ) Inappropriate Skills تجربههاي ناكافي و غيرمقتضي تيم پروژه) Lack of Testing and QA(Quality Assurance) standards (نقصان استانداردهاي تست و تضمين كيفيت) ) Users and Organizations Resistances مقاومتهاي كاربران و سازمانها در پذيرش سيستمهاي جديد) |
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
|
|
بطور کلی دلایل اصلی شکست پروژههای ITدر ایران را می توان به دو دسته ی عوامل داخلی و خارجی تقسیم کرد: عوامل داخلی: -مدیران پروژه کم تجربه -ناتوانیهای شرکتهای تولید نرم افزار -قراردادهای ناپخته -کمبود نیروی انسانی متخصص -مقاومت های کاربران و سازمانها در پذیرش سیستم های جدید -ارتباط با مشتریان و کاربران و عدم درگیر نمودن کاربران در پروژه عوامل خارجی: -نبود سرمایه گذاری مناسب برای پژوهش و تحقیق در حوزه نرم افزار -سرمایه گذاری کم در بخش خصوصی و عدم حمایت دولت -عدم استفاده از یک استاندارد واحد -مشکلات حضور در مناقصات بین المللی -ارزان بودن نرم افزار و عدم در نظر گرفتن ان بصورت یک کالا -ما ه های سال، تعطیلات رسمی و برنامه ریزی زمانی -ا دغام شوراها -عدم شناسایی حقوق مولفین وقانون کپی رایت - تحریم ایران -مشکلات موجود کشور در زمینه مستندسازی تولید محصولات نرم و رعایت نکردن مستندات تعریف شده نرم افزاری |
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
|
|
شکست پروزه VPN پروژه ملی ساماندهی VPN یا قانونیسازی آن که گویا طبق گفتههای مدیر عامل زیرساخت با شکست مواجه شده و آثار زیانباری را برای مشترکان داشته است و نحوه جبران این خسارتها هنوز مشخص نیست، اقدامی در راستای یکپارچهسازی بسترهای خارجی ارتباطات اینترنتی بود. با توجه به اینکه فعالیت در بخش تولید نرمافزارهای فیلترشکن نیاز به علم نرمافزاری دارد و فعالان خلاق در این حوزه به راحتی میتوانند از پس این کار برآیند، نظارت بر آن بسیار مشکل است و حتی اگر برخورد سلبی با این موضوع صورت گیرد و درگاههای ارتباطی VPN بسته شود، باز هم برای خلاقان راههای گریز بسیاری وجود دارد. محسن امیری با اشاره به اینکه در قانون جرائم رایانهای نیز به این موضوع اشاره و در بند اول دسترسیهای غیرمجاز آن قید شده " هر کس به طور غیر مجاز به دادهها یا سامانههای رایانهای یا مخابراتی که به وسیله تدابیر امنیتی حفاظت شده است دسترسی یابد، به حبس از ۹۱ روز تا یک سال یا جزای نقدی از پنج میلیون ریال تا بیست میلیون ریال یا هر دو مجازات محکوم خواهد شد"، اما باز هم تا اختلالی در کار مشترکان ایجاد و شکایتی صورت نگیرد، قانون به سراغ خاطیان نمیرود. وی گفت: سبب این موضوع هم مشخص است؛ اطلاعات درست و کاملی از فروشندگان و تولیدکنندگان پورتهای VPN در دست نیست زیرا تمامی آنها از سرورهای خارجی و رجیسترهای خارج از مرز استفاده میکنند و با اشتراکی که به مشترکان میفروشند، حق استفاده را برای آنها به وجود میآورند. او ادامه داد: موضوع VPN قانونی هم که در راستای نظارت بیشتر بر این حوزه مطرح شده، به دنبال این بود که فضای گسترده اینترنت را زیر بال و پر خود بیاورد در حالیکه عملا این کار نشدنی به نظر میرسد. این کارشناس فضای مجازی با اشاره به اینکه تولید درگاهها و پورتهای تازه، چندان کار سختی نیست، عنوان کرد: قانون درصدد بود تا با ارائه خدمات قانونی و قابل رصد، مبارزهای سرسختانه با فعالیتهای غیر قانونی داشته باشد و پورتهای مسیردهنده غیرقانونی را به محض تولید، مسدود کند. اما تمامی این موضوعات در حالی مطرح است که بازخورد عملی اجرای این طرح نیز با شکست مواجه شده چرا که تعداد ثبتنام کنندگان حقوقی در حدود ۲۰ تا ۳۰ شرکت بودهاند و عملا سرمایه میلیاردی زیرساخت دور ریز شده است. درگاه ثبتنام این خدمت که حدود یک ماه و نیم پیش آماده ثبتنام از کاربران حقیقی بود، به یکباره از دسترس خارج شد و خسروی –مدیر عامل زیرساخت- هم که خبر از آمادگی این شرکت برای خدمترسانی به این قشر داده بود بعد از چند روز مطرح کرد: از سوی فضای مجازی از شرکت ما خواسته شد تا زیرساخت vpnرا به صورت قانونی در اختیار شرکتها و مردم قرار دهد اما علیرغم تمام تبلیغاتی که صورت گرفت و میلیادرها تومان برای این پروژه هزینه شد، استقبالی از این طرح نشد و فقط ۲۶ شرکت برای vpn قانونی ثبت نام کردند. او ادامه داد: بسیاری از شرکتهای خصوصی، سفارتخانهها و بخشهای خصوصی اصلاً نیامدهاند تا از این مسیر استفاده کنند و میبینیم که عوارض بسیاری به وجود آوردهاند و این معضل هنوز وجود دارد و نمیدانیم بسیاری از این مشکلاتی که برای مشتریان به وجود آمده را چگونه میشود حل کرد. امیری در انتها یادآور شد: برای نظامند کردن این بخش، بهتر است که قانون واحدی در بخش جرائم رایانهای داشته باشیم و پایبند به آن عمل کنیم و پلیس سایبریها را مسئول اجرایی قرار دهیم چرا که اگر غیر از این باشد، هر روز باید به فکر تولیدات و ساخت محصولات نوینی باشیم که در مقابله با راهکارهای مجرمانه اندیشیده میشود و این با توجه به گستردگی فضای مجازی، امری بیهوده است. |
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
|
|
با توجه به صحبت هایی که با یکی از دوستان فعال در زمینه فناوری اطلاعات و ارتباطات می کردم مطالبی هست که مشخصا باعث شکست برخی از پروژه های بزرگ نرم افزاری می شه هر کدوم از موارد زیر که درست انجام نشن موجب شکست سنگین در پروژه می شن ***** نیاز سنجی: این امر باید دقیقا توسط کارکنان سازمان بصورت کاملا حرفه ای و تجربی شناسایی بشه و بصورت کاملا سیستماتیک مستند بشه نیاز هست که ترجمه این نیاز برای مجریان و پیمانکاران به صورت کاملا دقیق و جزئی باشه تا پیمانکاران بتونن دقیقا همون نیاز رو پیاده سازی کنن ***** امکان سنجی اینکه نیاز درست شناسایی بشه بسیار بسیار مهمه اما اینکه آیا امکان سیستماتیک کردن و مکانیزه کردن کامل یک نیاز وجود داره یا خیر از اون مهم تره ***** هزینه سنجی گاهی انجام سنتی یک فرآیند کوچک بسیار مقرون به صرفه تر از مکانیزه کردن اون هست و گاهی هم اتوماسیون فرآیند ها اونقدر در هزینه ها تاثیر گزار هست که تسریع و اولویت پروژه در دستور کار قرار می گیره ***** زمان بندی دقیق با توجه به هزینه، درخواست، امکانات و شرایط موجود بایستی زمان پیش مطالعه و اجرای طرح کاملا مورد بررسی قرار گیرد تا کارفرما و پیمانکار زمان لازم و کافی را برای اجرای تعهدات خود داشته باشند در صورتی که کارفرما زمان لازم و کافی را در جهت مطالعه کامل طرح توسط پیمانکار نداشته باشد طرح با شکست مواجه می شود و در صورتی که پیمانکار در زمان مشخص شده نتواند به تعهدات خویش عمل کند پروژه عملا شکست خورده است زمان سنجی می بایست دقیق و منطقی باشد و اهرم های فشار کارفرما می تواند شکست های سنگینی را به پروژه تحمیل کند ***** انتخاب درست و دقیق مجری از دسته مهمترین موارد اجرایی هست گاهی یک مجری هزینه کمی می گیره تا یک پروژه رو انجام بده غافل از اینکه این مجری بعلت تجربه کم یا غیر مرتبط در زمینه مورد درخواست پروژه رو با عدم مطالعه دقیق به شکست می کشونه بنا بر این همیشه قیمت نباید فاکتور اصلی انتخاب پیمان کار باشه ***** تحلیل درست درخواست باید حتما توسط سه تیم حرفه ای و مسلط انجام بشه یک تیم از کارفرما یک تیم از پیمانکار و تیم سوم یک تیم حرفه ای از مهندسین صنایع و کامپیوتر هست که باید زبان مشترک کارفرما و پیمانکار رو بدونن و در صورت نیاز نظارت کامل رو بر کل پروژه داشته باشن پس از انجام مراحل فوق نوبت به ***** پیاده سازی، استقرار، اجرا، عملیاتی سازی ، تست، تغییر، ارتقاء، پشتیبانی، نگهداری، آموزش و .... می رسد هر یک از مراحل فوق می بایست طبق استاندارد های موجود انجام شوند در غیر این صورت پروژه با شکست مواجه خواهد شد |
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
|
|
با سلام و احترام معرفی پروژه 1: نرم افزاری که مربوط به باز نویسی یکی از نمایندگی های تعمییرات سونی بود. اصل پروژه یک نرم افزار تحت داس بود که همه کارها در همان صفحه اصلی انجام می شد. وظیفه ما باز نویسی نرم افزار و طبق توافق با کافرما فروش آن به سایر نمایندگی ها بود. نرم افزار به اتمام رسید و این بار علی رغم تعامل و ارتباط موثری که با کارفرما داشتیم نرم افزار در آخر مورد استفاده قرار نگرفت. بررسی شکست: نرم افزاری که همه امورات آن در یک صفحه انجام می شد و خیلی ساده بود ، بصورت روندی و کارتابلی در آوردیم و قضیه پیچیده تر از آن شد که کاربران بتوانند از آن استفاده کنند.البته اشتباه در انتخاب پلت فرم و تحت وب کردن نرم افزار نیز زیاد بی تاثیر نبود. چون کاربران سالها از نرم افزار داس استفاده کرده بودند و به زبان ساده از محیط تحت وب نفرت داشتند. معرفی پروژه 2 : پروژه مربوط به بازنویسی نرم افزار تحت داس یکی از نمایندگی های شرکت هپکو بود . بعد از اتمام نرم افزار مورد استفاده قرار گرفت ولی 30 درصد نرم افزار را مجبور شدیم دوباره از اول بنویسیم و نهایتا پروژه دیر تحویل داده شد. البته این نرم افزار به مدت پنج سال است که بدون کوچکترین توقف و بدون پشتیبانی مورد استفاده قرار می گیرد. بررسی شکست : برخی سناریوها و روند های موجود در نرم افزار را که گاها غلط و تکراری بودند را از اول طراحی کنیم . حق واقعا با ما بود و این سناریوها واقعا باید عوض می شدند اما چون بدون هماهنگی و تائید کارفرما بود و نیز چون به این روند ها عادت کرده بودند نتوانستیم آنها را قانع کنیم و مجبورا تغییرات را حذف کرده و چیزی شبیه به مدل خودشان ساختیم. معرفی پروژه 3 : نرم افزاری که وظیفه اصلی آن صرفا آرشیو اسناد بود و در عین سادگی بسیار کاربردی و قوی بود ،و در بسیاری از مراکز دولتی استفاده می شد در نسخه دوم قرار شد نرم افزار را گسترش داده و ایده های جدیدی در آن اعمال کنیم. نسخه دوم در مرحله کدنویسی متوقف شد. بررسی شکست : شکست این پروژه چندین علت داشت اول اینکه هیچ کدام از ذینفعان پروژه دید مشترکی نسبت به نرم افزار نداشتند و اینکه هدف نرم افزار چه بود و بعد از اتمام نرم افزار قرار است چه کند از نگاه هر کسی چیزی متفاوت بود.و محدوه نرم افزار دقیقا مشخص نشد و اینها باعث شد در مرحله تحلیل اختلافات اساسی بین اعضای تیم بوجود آید . همچنین در پروژه بیش از دو مورد تکنولوژی جدید که برای برنامه نویسان نا آشنا بود به کار گرفته شد که ادامه کار را با مشکل مواجه کرد. |
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
|
|
ده پروژه شکست خورده "Google" را بشناسید
google lively شکست خـورد ايـــده عالي، اجـــــرا فاجعه
گوگل زنده يا google lively نمونه جالبي از اصطلاح «ايده عالي، اجرا فاجعه» است و چه دليلي بهتر از اين که نه ما و نه شما هرگز اسمي هم از اين پروژه گوگل نشنيديم اگر چه براي شش ماه تمام در سال ۲۰۰۸ اجرا مي شد. اين پروژه وقتي اجرا شد که پروژه زندگي دوم يا second life و يا محيط هاي مجازي مشابه اداشتند کم رنگ و کم رنگ تر مي شدند. در شبکه اجتماعي گوگل زنده کاربران براي خود يک آواتار مي ساختند تا بتوانند در محيط سه بعدي با ديگران ارتباط برقرار کنند. در اين محيط مجازي که معماري مختص خودش را داشت افراد مي توانستند با هم دوست شوند و حرف بزنند و به جاهايي که دوست دارند سر بزنند. افرادي که اين محيط را تجربه کرده بودند از مشکلات متعدد و اعصاب خرد کن سرور شاکي بودند ولي ايده اصلي به نظرشان جذاب بود. اتاق هاي چت تقريبا هم عمر خود اينترنت هستند و در آنها مي توان با آشنايان و غريبه ها حرف زد. با پيشرفت وب کم ها چت تصويري نيز تبديل به پيش فرض ما براي برقراري ارتباط با دوستان و آشنايانمان شده است. ولي چرا پروژه گوگل زنده و يا نمونه هاي مشابه آن نگرفت؟ اين روزها ما براي آشنايي با افراد غريبه از شبکه هاي اجتماعي استفاده مي کنيم و غريبه ها را از روي علايق مشترکي که داريم به دايره آشناهايمان راه مي دهيم. اغلب شبکه هاي اجتماعي پرکاربرد مانند فيس بوک، توييتر و يا شبکه هاي ايراني مانند ني ني سايت داشتن تجربه مشترک را پايه و اساس جمع کردن افراد دور هم قرار مي دهد.در شروع دنياي اينترنت جاهايي مانند زندگي دوم يا گوگل زنده قرار بود جايي باشند که ما گاهي به آنها سر مي زنيم. مثل سر زدن به شهربازي يا کافي شاپ در زندگي واقعي. ولي اينترنت خيلي فراتر از آن چيزي شد که در ابتدا تصور مي کرديم و امروزه ارتباط با غريبه ها کاري نيست که هر از گاهي انجام بدهيم بلکه جزو اصلي زندگي روزانه ما شده است.
google answers شـــکست خورد جستجو کافي است. پاسخ لازم نيست
«گوگل پاسخ» پروژه ديگري است که اين روزها رها شده است. اصولا در دنيايي که جواب هر سوالي را با يک جستجوي ساده در گوگل مي توان پيدا کرد مفهوم «پاسخ» با آن چيزي که قبلا بود عوض شده است. اگر چه «ياهو پاسخ» هنوز وجود دارد و به کارش ادامه مي دهد ولي اين به خاطر اين نيست که او دارد واقعا پاسخي را به سوالها ارايه مي کند بلکه به اين دليل است که پاسخهايش عجيب و غريب و سرگرم کننده هستند.
وقتي شما به اطلاعات حقيقي احتياج داريد يا در گوگل جستجو مي کنيد و يا به وب سايتهاي تخصصي حوزه خود مي رويد و دنبال پاسخ خود مي گرديد بعضي وقتها هم از شبکه هاي اجتماعي خود استفاده مي کنيد و از دوستاني که مي شناسيد و به آنها اعتماد داريد سوال خود را مي پرسيد. دوباره مي بينيم که ايده اصلي تغيير ماهيت داد. اين که جايي باشد که کاملا جهاني است و پاسخ هر سوالي که هر کسي مي پرسد را دارد تبديل شد به يک نمونه شدني تر و انساني تر اما چطور مي شود که شرکتهاي زيادي روي ايده پاسخ دادن به همه سوالات ممکن سرمايه گذاري مي کنند؟ شرکتهايي مانند چاچا و يا askJeeves که ايده شان اين است که يک سوال درباره هر چيزي که مي خواهي بپرس و پاسخت را دريافت کن.
اما حقيقت اين است که آنها اصلا دنبال درست کردن چيزي مثل «گوگل پاسخ» نيستند بلکه کاري که مي کنند اين است که سوال شما را در گوگل جستجو مي کنند و نتيجه را به شما نشان مي دهند. استفاده از آنها مثل اين مي ماند که از شخص ديگري بخواهيد چيزي را در گوگل برايتان جستجو کند. براي اين که ايده «گوگل پاسخ» حتي بيشتر منجر به شکست بشود گوگل براي دريافت برخي از پاسخ ها با يک جور مدل مزايده اي به مترجمان آزاد پول مي داد. الان ناموفق بودن اين ايده بديهي است ولي مابين سالهاي ۲۰۰۲ تا ۲۰۰۶ که اين پروژه اجرا مي شد هنوز قابليتهاي عظيم اينترنت و حجم عظيم اطلاعاتي که بر روي آن يافت مي شود بر همگان مشخص نبود و گوگل خودش مي خواست اين خدمات را ارايه کند.
تبليغات چاپي و راديويي گوگل شکست خورد از اينتــــــرنت پول دربياور نه از بيرون آن! جمله معروفي است که اين روزها شعار اغلب وب سايتها شده: از اينترنت پول در بياور. ولي چند سال قبل گوگل درست برعکس اين شعار حرکت کرد و تصميم گرفت از بيرون از اينترنت پول دربياورد. شايد تحت تاثير فشار روزافزون براي کسب درآمد بيشتر گوگل تصميم گرفت وارد صنعت تبليغات چاپي و راديويي شود. البته با اتکا به داده هاي بسيار زيادي که درباره کاربران و محصولات مورد علاقه شان داشت. البته اطلاعات شخصي مصرف کنندگان حکم قلک پر از طلايي است که گوگل دارد و در آينده پيش رو هم حتما از آن استفاده هاي زيادي خواهد کرد ولي با توجه به اين که اطلاعات هر روز بيشتر و بيشتر در دسترس همگان قرار مي گيرد استفاده از تبليغات براي پول درآوردن کماکان مهم ترين روش درآمدزايي است. استفاده از اطلاعات گوگل براي هدف قرار دادن مصرف کنندگان در بيرون از دنياي اينترنت ممکن است در تئوري بسيار جالب به نظر برسد ولي مشکل اين جا است که روشهاي قديمي براي برقراري ارتباط با مصرف کنندگان دارند از بين مي روند و عاقلانه نيست که گوگل در آن بازار سرمايه گذاري کند.
از طرف ديگر روشهايي که گوگل براي تعيين بهترين نقطه براي يک تبليغ اينترنتي دارد به همان خوبي در دنياي خارج جواب نمي دهد و مديران حوزه تبليغات راديويي و چاپي به مرور فهميدند تمايلشان به استفاده از روشهاي خودشان بيشتر از روشهاي به دست آمده از داده هاي گوگل است.
dodgeball شکسـت خورد ايــده پرداز قهـر کرد و رفت
در سال ۲۰۰۵ دو تا از پروژه هاي گوگل همزمان بيرون آمدند: آندرويد و داجبال (Dodgeball). بديهي است که اين جا لازم نيست از موفقيت آندرويد صحبت کنيم اما ماجراي داجبال جالب است. داجبال يک شبکه اجتماعي حساس به مکان بود و در سال ۲۰۰۵ شروع به کار کرد. اين محصول نيز ترکيبي است از نگاه به آينده و زندگي واقعي و تلاش براي ترکيب اين دو . اين اپليکيشن قرار بود از گوشي هاي هوشمند استفاده کند تا افراد را به هم وصل کند و مثلا جاهايي که يک نفر مي رود يا رستوران خوبي را که پيدا مي کند با کساني که مي شناسد و در منطقه هستند به اشتراک بگذارد.
خب چه بر سر اين ايده آمد؟ براي دو سال پروژه به خوبي پيش رفت تا اين که دنيس کراولي که ايده پرداز اوليه اين طرح بود در سال ۲۰۰۷ از گوگل بيرون آمد و شرکت فوراسکور را تاسيس کرد و اين شرکت که دقيقا همين خدمات را ارايه مي دهد الان بسيار محبوب است.
مشکل اين طرح در زمان خودش اين بود که زيادي آينده نگر بود و سخت افزار لازم براي فراگير شدن آن که همان گوشي هاي هوشمند بودند خيلي طول کشيد تا غالب بازار شود. امروزه گوگل latitude را دارد که همان کار را مي کند. البته اين خدمت آنلاين گوگل اصلا جذابيت فوراسکور را ندارد و شايد يک دليل آن قسمت بامزه بازي فوراسکور است که کاربران مي توانند ميزان علاقه و وفاداري خود را به يک کسب و کار و يا فروشگاه خاص نشان دهند. ولي از اين خصوصيات مهم تر اين است که استفاده از فوراسکور خيلي راحت تر از توييت کردن محلي که هستيم براي دوستانمان و يا انتشار آن در فيس بوک است. اين طرحي است که مي توانست از آن گوگل باشد و او با بي درايتي از دست داد.
جــــايکو شــــکست خــــورد توييتر قبلا اين ايده را پياده کرده بود
گوگل در سال ۲۰۰۷ يک سايت براي بلاگ هاي بسيار کوچک راه انداخت که جايکو نام داشت ولي تا سال ۲۰۰۹ معلوم شد که اين توييتر است که فاتح دنياي پستهاي کوتاه و سريع است. يک شبکه اجتماعي همان قدر قدرتمند است که کاربرانش قدرتمند باشند و توييتر در زماني که جايکو راه افتاد بيش از نصف راه موفقيتش را رفته بود. اگر چه هنگامي که جايکو از کار افتاد عده اي از کاربران سينه چاکش يک سيستم آرشيوي درست کردند تا تمام مکالمات خود را جايي ذخيره کنند و براي هميشه داشته باشند.
شايعات زيادي درباره دلايل دست شستن گوگل از جايکو وجود دارد ولي به هر حال اين پايان شروعي بود براي يک جور ميکروبلاگهاي کوچک که پستهاي اشخاص روي آن شکل هايکو همان شعرهاي معروف ژاپني را دارد.
google notebook شکست خورد احــــــتمالا پيـــــچيده بـــود
گوگل نوت بوک در سال ۲۰۰۹ از مجموعه پروژه هاي گوگل کنار گذاشته شد.اگر چه گوگل داک کمابيش به آن سرويس داکيومنت اشتراکي که گوگل همواره دنبالش بود تبديل شده است شرکت گوگل هيچ گاه نتوانست در رقابتي که در اين حوزه وجود دارد از اپليکيشن هاي ديگر همچون evernote پيشي بگيرد. کپي کردن کليپهايي که آدرس اينترنتي شان را حفظ مي کنند به نظر يک امر بديهي مي رسد به خصوص اگر با مرورگر ترکيب شود. به همين دليل است که گوگل سالهاست دارد اين ايده را دنبال کند. اما باز هم وقتي همه تلاشها انجام مي شود و نوبت به آمار و ارقام مي رسد به نظر مي رسد کاربران سرويس هاي ديگر غير از گوگل را ترجيح مي دهند. معلوم نيست مشکل از پيچيدگي فراوان ابزارهاي گوگل است و يا رابط کاربري سرويس گوگل خوب نيست ولي دنياي ابزار نگارش در اختيار آن دسته از توسعه دهندگان است که ابزارهاي ساده و بسيار دم دستي توليد مي کنند. آن هم در حالي که پردازش ابري امکان ارسال نوشته ها را به خانه، محل کار و هر جاي ديگري به راحتي فراهم مي کند.
google Buzz شـــکســت خورد اعـــصاب کاربران را خرد کرده بود
خيلي از ايرانيان مرگ گوگل باز را به ياد دارند. کاربران ايراني شايد يکي از معدود گروه هايي بودند که عاشقانه گوگل باز را مي پرستيدند و از آن استفاده مي کردند ولي به هر حال گوگل مجبور شد آن را کنار بگذارد. اولين اشتباه گوگل باز اين بود که با کاربران صادق نبود. در فوريه سال ۲۰۱۰ اين خدمت گوگل به طور اتوماتيک به جي ميل اضافه شد و اضافه شدن دکمه باز در کنار اينباکس بدون هيچ گونه اطلاع رساني به مخاطبان صورت گرفت.
اما چه چيزي درون اين فولدر جديد بود؟ اين همان گوگل ريدر بود که يک تجربه بسيار موفق در زمان خودش بود. گوگل ريدر با استفاده از rss قابليتي ايجاد کرده بود که خوانندگان بتوانند سايتهاي محبوب خود را دنبال کنند. کار گوگل باعث شد که يک فولدر جديد به جي ميل افراد اضافه شود که هميشه در آن تعداد بسيار زيادي مطلب خوانده نشده وجود دارد و گوگل هيچ وقت نفهميد که اين فولدر اضافي چه بار سنگيني به مخاطبانش وارد مي کند. در سال ۲۰۱۱ گوگل پروژه باز را از ليست پروژه هايش کنار گذاشت.
sidewiki شــــکست خورد ويکي پديا رقـابت ناپذير است
گذشته خيلي وقتها چندان شفاف نيست ولي اغلب ما آن دوران را به ياد داريم که هنوز ويکي پديا به وجود نيامده بود. چيزي که ويکي پديا را منحصر به فرد مي کند جامعه بزرگ و بسيار وفادار آن است که وقت خود را براي توسعه هر چه بهتر آن مي گذارند و برعکس آنچه بسياري از افراد مي گويند اين که هر کسي مي تواند مطالب آن را ويرايش کنند اصلا از اعتبار مطالب کم نمي کند.
اما همه اينها چه ربطي به گوگل دارد؟ سه پروژه searchwikiو knol و Sidewiki دليل اين مقدمه هستند.همه اضافات ويکي پديا و گزينه هايي که مي توانند جايگزين آن شوند از تابستان ۲۰۰۸ توسط گوگل توسعه داده شده است. knol پروژه توليد يک مجموعه از دست نوشته هاي کاربران است. searchwiki به کاربران اجازه مي دهد نتايج جستجو را رتبه بندي و امتياز دهي کنند و آخرين پروژه يعني sidewiki که روي مرورگر اضافه مي شود و اجازه مي دهد که وب سايتها را برچسب گذاري بکنيم. پروژه sidewikiعملا رها شده است و دو پروژه ديگر هم نتوانسته اند به موفقيت پيش بيني شده دست پيدا کنند.
همه کوشش ها براي توليد چيزي مانند ويکي پديا حتي آنهايي که توسط کاربران عاشق پيشه گوگل پشتيباني مي شدند نتوانستند به اندازه هاي بزرگي برسند و حتي پروژه knol در بهار سال ۲۰۱۲ به پشت ديوارها فرستاده شد. شايد اگر يک رابط کاربر متفاوت براي knol طراحي مي شد مي توانست هنوز مقاومت کند ولي مساله اين است که ويکي پديا خيلي قوي است و خدماتي که به کاربران در هر سطحي ارايه مي دهد بسيار مفيد هستند. از کاربران کاملا بي اطلاع نسبت به موضوع تا حرفه اي هاي هر حوزه آن را مي خوانند و مي توانند با آن ارتباط برقرار کنند و اين واقعا تعجب آور است. اگر خوب به فلسفه پشت آن بينديشيم مي بينيم اين که همه مي توانند به خانواده ويکي پديا بپيوندند چه براي استفاده از مطالب و چه براي توليد آنها و اين موضوعي استثنايي در تاريخ دنيا است.
در پروژه searchwiki مشکل اين بود که کاربران علاقه نداشتند تغييري در رتبه بندي گوگل ايجاد کنند به خاطر همين هم در سال ۲۰۱۰ اين پروژه با يک سيستم ستاره دهي جايگزين شد. در پروژه sidewiki کاربران هيچ وقت از کامنت هايي که در سايدبار وجود داشت استفاده نمي کردند و به همين خاطر هم گوگل اين پروژه را در سپتامبر ۲۰۱۱ رها کرد.
google video شکــــست خـورد مشکل با خريـــــد يوتيوب حل شد
گوگل ويدئو تلاش کرد تا يوتيوب را در هم بشکند و شکست خورد و تنها دليلش اين بود که اين ابزار قبلا وجود داشت و نامش هم يوتيوب بود. بعد از آن البته گوگل يوتيوب را با قيمت ۱.۶۵ ميليون دلار خريد و قال قضيه را کند و آخر سر همه خوشحال و راضي بودند. داستان گوگل ويديو تنها داستان يک حمله بي کله به يک کرگدن اينترنتي نبود. حقيقت امر خيلي عجيب تر از اين هاست. در ژانويه ۲۰۰۵ ريشه هاي چيزي که قرار بود گوگل ويديو شود در تبديل پخش تلويزيوني به متنهاي قابل جستجو شکل گرفت. در تابستان اين سال آنها شروع به پشتيباني از آپلودهاي ويديويي و به اشتراک گذاشتن آنها کردند و در انتهاي اولين سال شکل گيري آن، ايده اوليه تبديل گفتار تلويزيوني به متنهاي قابل جستجو کاملا از دست رفته بود. اگر چه در سال ۲۰۱۲ نمونه هايي از متن فيلمهاي ويديويي در يوتيوب ديده مي شود و نشان مي دهد که گوگل هنوز ايده اوليه را در سر دارد.
هر دليلي که باعث جذابيت و فراگيري سايتهايي مي شود که بر مبناي تجربيات کاربران طراحي مي شوند را در نظر بگيريد. گوگل ويديو کاملا بر خلاف آن حرکت کرد. آنها تصميم گرفتند يک نوع فايل اختصاصي با پلير مخصوص خودش را معرفي کند که به طرز چشم گيري مجموعه کارهايي که کاربر بايد انجام مي داد تا محتواي ويديويي خودش را داشته باشد زياد مي کرد. بعضي وقتها اين روش جواب مي دهد. بالاخره همه پليرها و انواع مختلف فايلهاي ويديويي از يک جايي آمده اند ديگر. ولي اين استراتژي براي وقتي که شما يک دعواي بزرگ را با سايت بسيار راحتي مانند يوتيوب شروع کرده ايد اصلا جواب نمي دهد. سايتي که محبوبيتش آن را تبديل به يک جور استاندارد در دنياي ويديو ها کرده است. ايده داشتن يک پلير و فرمت فايل اختصاصي در زماني که همه ابزار ها و نمايشگرها به دنبال پشتيباني هر چه بيشتر از فرمتهاي موجود مي روند يک جور خود کشي به حساب مي آيد.
بعد از اين که گوگل ويديو نتوانست با يوتيوب رقابت کند تصميم گرفت مدلش را عوض کند و تبديل به يک مرجع اجاره دادن ويديو ها شود و اين بار هم قبل از آن يک رقيب قدرتمند به نام نت فليکس در اين بازار بود که عينا همين سرويس را ارايه مي کرد و به خاط همين گوگل ويديو آن را هم رها کرد و در نهايت گوگل يوتيوب را خريد و به اين داستان خاتمه داد.
google wave شکــــــست خورد شايد آيندگان بپسندند، ما نپسنديديم
بزرگترين شکست گوگل را شايد بتوان گوگل موج (google wave) دانست. مجموعه اي از قابليتهاي بي فايده که با يک روش پيچيده و غير لازم دور هم جمع شده اند. گوگل موج مي خواست براي همه، همه چيز در حوزه اشتراک محتوا باشد. همان طور که گوگل پلاس تلاش مي کند براي کاربران شبکه هاي اجتماعي همه چيز باشد. هنوز معلوم نيست سرنوشت پلاس چه مي شود ولي مجلس ختم گوگل موج مدتهاست که برگزار شده و عزاداري ها هم انجام شده است.
مي خواهيد يک ايميل بفرستيد؟ مي توانيد از جي ميل استفاده کنيد. ولي اگر به هر دليلي خواستيد آن را به ليست غير قابل فهمي از افراد بي ربط و از طريق يک مسير بسيار غير طبيعي ارسال کنيد گوگل موج مي تواند کمکتان کند. آيا مي خواهيد آن ايميل را تبديل به يک آهنگ يا ويديو يا مکالمه اي درباره آهنگها و يا ويديو ها يي بکنيد که درون خودش آن آهنگ و يا ويديو را هم دارد؟ آيا مي خواهيد با شعبده بازي آدم هاي ديگر را وارد مکالمه بکنيد و يا از آن خارج کنيد جوري که خودتان هم نفهميد با کي داريد صحبت مي کنيد و آيا اصلا کسي حرفهايتان را دنبال مي کند يا نه؟ آيا دوست داريد هميشه امکان اين را داشته باشيد که در کنار مکالمه فعلي يک مکالمه ديگر راه بيندازيد و خودتان را در اين پارانوياي دايمي بيندازيد که بقيه دارند همزمان هم با شما حرف مي زنند و هم پشت سرتان حرف مي زنند؟
البته واضح است که گوگل موج اين قدرها هم بد نبود ولي مشکل آن همان مشکل اشتباه در پيش بيني نيازهاي کاربران بود. مساله اين است که حتي حرفه اي ها هم نمي توانند بگويند چرا گوگل موج اين قدر با بي مهري رو به رو شد. يکي از دلايل آن پيچيدگي زبان ارتباطي آن بود و از آن مهم تر ناتواني آن در برقراري ارتباط با ساير خدمات گوگل . برخي معتقدند گوگل موج هم دچار مشکل «جاي درست، زمان نادرست» شده و شايد در آينده موفقيت کسب کند.
منبع : بایت http://www.yjc.ir/fa/news/4677178/%D8%AF%D9%87-%D9%BE%D8%B1%D9%88%DA%98%D9%87-%D8%B4%DA%A9%D8%B3%D8%AA-%D8%AE%D9%88%D8%B1%D8%AF%D9%87-google-%D8%B1%D8%A7-%D8%A8%D8%B4%D9%86%D8%A7%D8%B3%DB%8C%D8%AF |
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
|
|
شکست چیست؟
ابتدا لازم مینماید که بدانیم شکست در یک پروژه به چه معناست. شکست در پروژههای نرمافزاری در هر یک از چهار مورد «هزینه»، «زمان»، «کیفیت» و «دستیابی به اهداف» مطرح میگردد؛ بدین معنا که اگر پروژهای با صرف هزینهی بیشتر یا زمان بیشتر یا با کیفیت پایینتر انجام گردد، علیرغم به پایان رسیدن پروژه، آن را توأم با شکست میدانیم. منبع: http://itpms.persianblog.ir/post/3/ |
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
|
|
خلاصه مشخصات پروژه: بخش فناوري اطلاعات يکي از شرکت هاي مشهور کشور به عنوان کارفرما با يکي از شرکت هاي ناموفق در زمینه تولید نرم افزار به عنوان پیمانکار، اقدام به انعقاد قراردادي براي طراحي و تولید "سیستم نرم افزاري مديريت اسناد و مدارک" نمود. براي طراحي و تولید اين نرم افزار هیچ مناقصه اي برگزار نشد و صرفا بدلیل ارتباطاتي اين پروژه مستقیما به پیمانکار سپرده شد. (بدلیل سابقه همکاری چندين ساله با شرکت کارفرما از ذکر نام تجاري سیستم و نام شرکتها معذورم) اين پروژه با آرمان به حداقل رساندن حجم کارهای اضافی با بهترین بهره وری از منابع انسانی و ساير منابع براي شرکت هاي پروژه محور تعريف گرديد. اهداف پروژه: هدف از طراحي سیستم مديريت اسناد و مدارك تهیه شده عبارت بود از : - آسان سازي عملیات ذخیره و بازيابي کلیه مدارك تولید شده در شرکت - ذخیره سازي متمركز فايلها براي ايجاد يك بستر اشتراكي به همراه ايجاد روشي استاندارد براي دسترسي به مدارك - كنترل مدارك و بررسي نحوه دسترسي افراد مجاز به مدارك جهت بررسي روند ايجاد تغییرات و يا حذف و اضافه مدارك به صورت متمركز - دسترسي سريع و آسان به مدارك پروژه هاي قبلي براي استفاده مجدد در پروژه هاي جديد - آسان سازي عملیات و مديريت تهیه فايلهاي پشتیبان - پاسخ گويي به تعداد تقاضاهاي زياد کاربران در ساختمان هاي متعدد شرکت کارفرما - قابلیت انطباق و بهره گیری از ارتباطات شبکه کامپیوتري شرکت - و در نهایت بازايابي براي فروش اين سیستم در سطح شرکت هاي عضو جامعه مهندسین مشاور ايران نتیجه اجراي پروژه : پیمانکار انتخاب شده اقدام به تحلیل و استخراج ناقص نیازمندي هاي سیستم نمود. متاسفانه هزینه های پروژه با بي دقتي تمام استخراج گرديد بطوري که در نهایت هزینه تمام شده بیش از هفت برابر هزینه پیش بیني شده بود. اجراي پروژه طبق برنامه زمان بندي جلو نرفت و پروژه تعريف شده براي 9 ماه، بیش از دو سال بطول انجامید. پس از تحويل سیستم و آموزش به کاربران، ايرادات عجیبي در سیستم بروز نمود و باعث وقفه در عملیات شرکت شد. شرکت پیمانکار يکي از برنامه نويسان خود را بصورت مقیم در شرکت کارفرما مستقر نمود و با هزینه بالاي دستمزد ساعتي فرد مزبور، ايرادات بسیار کند مرتفع مي شدند و در نهایت هر قسمت از سیستم با شکل و شمايل متفاوت و بسیار گسترده تهیه شد که نیاز به آموزش در سه جلسه چهار ساعته داشت. سیستم فاقد HELP بود و خطاها بسیار زياد و بصورت CODE ظاهر مي شد. متاسفانه تقاضاي کاربران بدلیل مشکلات و کاربر پسند نبودن سیستم تهیه شده، روز به روز بیشتر شد و در نهایت سیستم به سمت توقف و شکست کامل پیش رفت. درس هاي گرفته شده از پروژه: در انتها درس هايي که از اين پروژه نرم افزاري شکست خورده مي توان گرفت بشرح زير است: - اهداف واقعي در نظر گرفته شوند. - نیازمندي ها بدرستي استخراج شوند. - مشخصات پروژه و تغییر نیازمندي ها بدرستي ديده شود. - سیستم نرم افزاري سفارش داده شده در قالب تعاملي با سیستم هاي انساني بتواند به خوبي به اهداف در نظر گرفته شده پاسخ دهد. - کیفیت نرم افزار سفارش داده شده از ديدگاه تناسب با هدف بدرستي اندازه گیري گردد. - منابع مورد نیاز بدرستي تخمین زده شوند. - سیاست هاي نگهداری مناسب اتخاذ گردد. - از وضعیت پروژه گزارش درست گرفته شود. - از فن آوري نرم افزاري ناكارآمد استفاده نشود. - روش هاي توسعه بدرستي صورت پذيرد. - ارتباطات قوي بین کلیه ذينفعان، شامل توسعه دهندگان و كاربران وجود داشته باشد. - کلیه ذينفعان در پروژه درگیر شوند. - پشتیاني قوي اجرايي میسر باشد. - مديريت ريسک بدرستي انجام شود. - مديريت قوي پروژه میسر باشد. - سیستم هاي سفارشي، قابلیت بروز شدن با فناوري هاي روز نرم افزاري را داشته باشند. - ناتواني فناوري مورد استفاده بدقت بررسي گردد. - از تجربیات متخصصان و شرکت هاي مشابه استفاده گردد. - پیش از طراحي نرم افزار، نرم افزارهاي آماده مشابه بررسي شوند. - با توجه به استقرار مديريت کیفیت در شرکت، نظام مديريت کیفیت از سوي پیمانکار اجرا شود. - فرايندهاي مهندسی نرم افزار بدرستي اجرا شوند. - سیستم پیش از عملیاتي شدن، در شرايط واقعي تست شود. - سیستم به عنوان يک مجموعه يکپارچه تست شود. |
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
|
|
تاریخچه مدیریت پروژههای نرم افزاری با تاریخچه تولید نرمافزار در هم آمیختهاست. نرمافزارها در آغاز برای مقاصد خاص و یا راهاندازی سخت افزارها نوشته میشد. اما با معرفی مفهوم برنامهنویسی شیگرا در سال ۱۹۶۰، برنامه نویسی با این رویکرد مورد استقبال شرکتهای توسعه نرم افزار قرار گرفت و در دهههای ۱۹۷۰ و ۱۹۸۰ روند تولید و توسعه نرم افزار رشد سریعی را تجربه کرد.
در این زمان شرکتهای تولیدکننده نرمافزار تلاش میکردند تا با استفاده از روشهای کلاسیک مدیریتی، پروژههای نرم افزاری را راهبری کنند اما به زودی و با کند شدن سرعت تولید نرم افزار و بروز مشکلات جدی در تست و نیز تغییرات به وجود آمده در نیازمندیهای مشتریان مشخص گردید که روشهای سنتی مدیریت پروژه برای راهبری تیمهای نرم افزاری مناسب نمیباشد. تحلیل و بررسی پروژههای نرم افزاری شکست خورده، عوامل زیر را به عنوان مهمترین دلایل شکست آنها مشخص کرد:
سه مورد نخست در فهرست بالا نشان میدهد که عدم بیان روشن و بدون ابهام نیازمندیهای نرمافزاری توسط مشتریان منجر به اشتباه در هدفگذاری و تخصیص منابع مورد نیاز پروژه میشود.[۱]
|
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
|
|
با سلام موردی که بنده به تشریح آن پرداخته ام اتوماسیون داخلی یک سازمان نوپا می باشد موردی که هیچ وقت در این مجموعه مورد اهمیت واقع نشد و حتی پس از شکست استقرار هم بی اهمیت ماند نیاز سنجی بود. در گام بعدی اینکه آیا یک اتوماسیون آماده که حتی قابل سفارشی سازی هست نیز می تواند نیاز این مجموعه را برطرف سازد یا نه. پس دو دلیلی که قبل از شروع باید به آنها پرداخته میشد در این مطالعه بررسی و تحلیل نشده بود. استقرار یک اتوماسیون اداری بسیار ساده، که میتوانست کار را در سازمان تسهیل دهد از روی عدم شناخت امکانات آن و عدم تحلیل درست از فرایندهای سازمان باعث شد تا به شکست منجر شود. در این مورد از نظر زمان، هزینه، انتخاب پیمانکار هیچ مشکلی وجود نداشته است و فقط تحلیل غلط از فرایندها باعث شکست پروژه شده است. |
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
|
|
عرض سلام و ادب و احترام خدمت تک تک دوستان اگر اجازه بدید بنده تمام این مبحث رو ملاحظه کنم و امتیاز فعالیت ها رو ثبت کنم بنا بر این خواهش می کنم از ساعت 24 روز 17 خرداد (بعد از امتحان) هیچ پستی رو اضافه نکنید بسیار بسیار متشکرم |
25 نظر
محمد زند / 10 شب / 5 دی 1395, / جواب
ارسال آرشیو محتوا
محمد زند / 10 شب / 5 دی 1395, / جواب
محتوای ارسالی از آرشیو 1393